[アップデート] AWS Step Functions の最適化された統合で EMR Serverless がサポートされ、よりシンプルなパイプライン実装が可能になりました

いわさです。

Apache Spark や Apache Hive などを使った分析ジョブをサーバーレスで実行するための環境として EMR Sereverless があります。

これまで EMR Serverless のジョブオーケストレーションのためには AWS Step Functions を組み合わせることが多かったのですが、Step Functions の「最適化された統合」が EMR Serverless のタスクではサポートされていなかったため、EMR Serverless の非同期特性の兼ね合いでワークフローが複雑になる傾向がありました。

Step Functions の EMR Serverless タスクで「Optimized」統合モードがサポート

本日のアップデートで EMR Serverless タスクでも Opmized、最適化された統合がサポートされるようになりました。

これによって既存のワークフローのステップを簡略化出来るようになります。

Step Functions の SDK 統合と最適化された統合

AWS Step Functions では AWS SDK で利用可能な多くの API が操作出来ますが、それらは単純に API を呼び出すだけのものです。
AWS Step Functions のタスクには「AWS SDK 統合」と「最適化された統合」が存在します。

SDK 統合は 2021 年にリリースされたもので、AWS SDK を使用した標準の API 呼び出しと同じように動作し、200 を超えるサービスで 9000 以上の API をステートマシンの定義から直接呼び出す機能が提供されています。

最適化された統合は Step Functions によってカスタマイズされ、ワークフローコンテキストに特別な機能を提供します。

例えば、Lambda Invoke は API 出力をエスケープした JSON 文字列から JSON オブジェクトに変換します。

また、ECS タスクの実行（ECS:RunTask）の例だと、AWS SDK 統合タイプの場合は次のように単純に RunTask を行うのみです。

最適化された統合タイプの場合だと、タスクが完了するまで待機させることが出来ます。(.sync オプション)

試してみる

では実際に Step Functions で EMR Serverless を用いたステートマシンを作成してみます。

EMR Serverless を SDK 統合で使う場合

EMR Serverless ではstartJobRunでジョブの実行を開始することが出来ますが非同期で処理されるため、後続のステップが必要なワークフローを構築したい場合はステータスのチェックや完了までの待機が必要でした。

次のような感じで一定間隔でGetJobRunでジョブステータスをチェックするイメージです。

EMR Serverless を最適化された統合で使う場合

今回のアップデートに併せて、Step Functions のテンプレートで最適化された統合タスクを使った EMR Serverless ジョブ実行のテンプレートが提供されています。

今回は、このテンプレートをベースに実装内容を確認してみます。
次のように、createApplication / startApplication / startJobRun / cancelJobRun / stopApplication で Optimized 統合タイプが選択されています。

ジョブはふたつ実行され、ひとつ目のジョブには「タスクが完了するまで待機」オプションが設定されているので、ひとつ目のジョブが完了した後にふたつ目のジョブが開始され、ふたつ目のジョブは完了を待機せずに次のステップでキャンセルされています。

コードでも確認してみるとひとつ目のジョブには.syncが付与されており、ふたつ目のジョブには付与されていません。

ステートマシンを実行してみましょう。
次のようにひとつ目のジョブが実行された後にジョブが完了するまで待機してくれています。

ふたつ目のジョブは完了を待たずにキャンセルされていますね。

さいごに

本日は AWS Step Functions の最適化された統合で EMR Serverless がサポートされたので、EMR Serverless のパイプラインを簡略化した状態でジョブの状態などを確認してみました。

今回のアップデートの恩恵を受けるのは EMR Serverless を使うワークロードのみですが、最適化された統合に移行することで冗長なタスクやフローを見直すことが出来そうです。

そもそもふたつの統合モードがあるのでうまく使っていきたいなというのを再認識しました。
非同期 API の完了待機については、AWS Batch や ECS でのタスク実行でも同じことが言えますね。